Multiple owner resource management

ABSTRACT

A method of management of resources in a multiple process system providing a list of resource owner identities, storing in an owner list the identity of at least one process with a resource which the at least one process has a right to operate, and allowing only a process listed with a resource to use the resource.

FIELD OF THE INVENTION

This invention relates to methods of managing resource elements such asthose used in telephone switching systems.

BACKGROUND TO THE INVENTION

Telephone switching systems such a PABXs and central offices providespecialized applications, such as automatic call distribution (ACD)which distributes incoming calls among agents. Such systems can be usedfor answering inquiries as to departure or arrival times of aircraft, totake reservations for theater, aircraft, trains, etc., to take telephoneorders, etc.

In such systems, when a subscriber calls a telephone number, such as an800 or 888 number, the telephone system routes the call to an idle agentwithin a hunt group of agents accessed by the number. All agents withinthe group are accessible by the same number, but the system determineswhich agent has been the "longest idle agent" and routes the call tothat agent.

U.S. Pat. No. 5,515,428, issued May 7, 1996, invented by Mark Sestak andPaul Erb, and assigned to Mitel Corporation, describes prior art methodsand a new method for keeping track of idle agents and for identifyingwhich agent is the longest idle agent. In such systems, when an agent isservicing a caller, the agent's line is marked as busy, and the agentbecomes unavailable for other calls. Thus in the event another callerattempts to call the agent, the request is denied.

However, it is sometimes necessary for the agent to access a supervisoror an information source line and conference the supervisor's orinformation line with that of the customer. With the agent's line beingmarked as busy, this has not been able to be done in such systems.

SUMMARY OF THE INVENTION

In accordance with an embodiment of the present invention, resourcessuch as agent's lines are listed, e.g. in a table, and processes foroperating various functions of the system, such as a process foroperating a supervisor's line, are entered against each resource. Pluralprocesses can be entered against a particular resource; all processesthat are entered against a particular resource are allowed to use theresource independently or together.

For example, assume that both an agent process and a supervisor processare entered in a list in the table with the agent resource. During acall in progress, the supervisor requests to join the call. By the useof the present invention, the associated supervisor process sends amessage the agent process and awaits an acknowledgment or rejection ofthe request. If the request is allowed, the three processes comprisingthe agent process, the calling party process and the supervisor processperform a hand-off of their associated lines to a conference process,which manages the lines until any party leaves the conference. At thispoint the conference process performs a hand-off of the parties back tothe original processes for subsequent handling.

Thus in such a system, even with the agent's line being marked as busy,the supervisor can join the conversation in a conference.

In the event additional callers are required to join the conference, theconference process accepts or rejects the request and exchanges messageswith all associated processes to add the new caller, if accepted.

The above process can be implemented with ownership management,ownership management being the subject of the present invention. Theownership management is preferably used in conjunction with the freelist described in the aforenoted patent.

In accordance with an embodiment of the present invention, a method ofmanagement of resources in a multiple process system is comprised ofproviding a list of resource owner identities, storing in an owner listthe identity of at least one process (process) with a resource withwhich the at least one process has a right to interact and use, allowingany process listed with a resource to use the resource, and barringaccess of the resource to other processes in the event there is at leastone process listed with the resource.

In accordance with another embodiment, the method includes providing afree list of available resources, marking a resource in the free list asbusy when the resource in the free list has a process stored with it inthe owner list, and marking the resource in the free list as idle whenthe resource in the free list has no process stored with it in the ownerlist.

It should be understood that the present invention is not restricted tobe used with ACD systems, but is applicable to the management of anyanalogous resource, the use of which can be controlled by the system.Thus while an example will be given of the use of the invention in anACD system, it can be used to manage any multiprocessing system whichcontains plural processes that must use and share resources amongstthemselves, such as a PABX or other system.

BRIEF INTRODUCTION TO THE DRAWINGS

A better understanding of the invention will be obtained by consideringthe detailed description below, with reference to the followingdrawings, in which:

FIG. 1 is a block diagram of a telephone switching system in which thepresent invention can be implemented;

FIG. 2 illustrates the content of a memory in FIG. 1 afterinitialization in accordance with the prior art;

FIG. 3 illustrates the content of the memory in FIG. 1 afterinitialization at a point during use;

FIG. 4 illustrates the content of the memory of FIG. 1 afterinitialization at another point during use;

FIG. 5 is an illustration of a free list data structure afterinitialization,

FIG. 6 is an illustration of a logical structure of an owner list andowner count in accordance with an embodiment of the invention,

FIG. 7 is a pseudo-code description of a function "can₋₋ become₋₋owner₋₋ of";

FIG. 8 is an illustration of a free list facilities data structure aftera process has become listed as an owner of a resource,

FIG. 9 is an illustration of a free list facilities data structure aftera second process has become listed as an owner of a resource,

FIG. 10 is an illustration of a free list facilities data structureafter the first owner process has become unlisted as an owner of aresource,

FIG. 11 is an illustration of a free list facilities data structureafter a second process has become unlisted as an owner of a resource.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

FIG. 1 illustrates a representative system in which the invention may becontained. The basic system may be as described for example in U.S. Pat.Nos. 4,616,360 and 4,615,028, invented by Conrad Lewis et al, which areincorporated herein by reference.

Basic elements of that system are a microprocessor 1 and a memory 3accessed by microprocessor 1, both of which are connected to a mainsystem bus 5. Memory 3 contains the main operation programs of thesystem as well as data as to the status and location of lines andtrunks, etc.

A circuit switch 7 and a message switch 9 are connected to bus 5 forcontrol by microprocessor 1. Peripheral control systems 11 are connectedto line circuits to which telephones 13 are connected, and are connectedto circuit switch 7 for switching telephone circuits between telephones13 and trunks in order that communication signals may pass therebetween.The peripheral control systems 11 are also connected to message switch9, whereby control messages from microprocessor 1 may be passed thereto,for controlling the line circuits or other peripheral circuits or forother well known peripheral control duties.

Agent terminals 17 such as telephones are connected to peripheralcontrol system 11.

In general the agent terminals are grouped into hunt groups (which maybe only a single hunt group or many hunt groups). When a call isreceived to e.g. a particular number such as an 800 number, themicroprocessor, comparing the called number with a hunt group liststored in memory 3, checks the number stored in memory 3 and routes thecall to one of the agent terminals 17A within the designated hunt group.

It should be recognized that in another design, an ACD circuit can beconnected to the main bus 5 and can be accessed directly bymicroprocessor 1 from that bus, or an ACD circuit can be connected to aperipheral control system 11. Whether agent terminals 17A are connectedto such ACD circuits or whether they are connected directly to linecircuits accessed by the peripheral control system 11 is notconsequential to the present invention. Techniques for detecting theoff-hook condition of a terminal and of connecting it to anotherterminal are well known, and a description thereof would be redundant.

In accordance with the prior art, to determine the oldest availableagent, a so-called free list of signals representative of the number ofeach available agent (i.e. the terminal number of that agent), eachassociated with one or more hunt group numbers, was stored. For example,each hunt group number "2000" would have the customer designated agentsassociated therewith, e.g. "5001", "5002" . . . "5010". The number ofrecords in the free list would be equivalent to the maximum number ofagents which could be programmed into the entire system. Each agentrecord is associated with a unique agent number.

When an agent logs onto the system, the agent number is added to the endof the free list, thus indicating that the agent is ready to receivecalls.

When a call arrives for a hunt group number, the microprocessor accessesthe free list and begins a search for the longest idle agent for thathunt group, starting from start to end of the free list. For every agenton the free list, the look-up checks to determine if the agent is amember of the desired hunt group. The first positive determination isthus an indication that the associated agent number designates thelongest idle agent, due to the ordering of the list. The microprocessorthen controls the telephone system to route the call to that longestidle agent, and the agent record is logically removed from the freelist. This is achieved by adjusting the free list linkages to skip theremoved record.

When the agent completes the servicing of the call and returns to theidle state, the agent record is logically added to the end of the freelist. Since that agent record is added to the end of the free list, therecords are automatically in the longest idle agent order if the freelist is traversed from beginning to end.

In prior art systems, memory 25 is provided connected to bus 5 foraccess by processor 1. Memory 25 is stand alone, or part of memory 3.

FIG. 2 illustrates the signal content of memory 25 immediately afterinitialization when all agents are idle. Memory 25 stores signals whichallow the processor to designate which agent (i.e. element) is to beused to service a call.

The stored signals are comprised of a header (record) 27 as well as afree list 29. The free list contains in successive memory locations 1,2, . . . N-1, N, the identifier of the next "longest-idle" agent.Traversing this list, we see that the longest idle agent is agent "1",followed by "2", "3" and so on. Somewhere in the system, there is anassociation agent "1" and the agent's extension number (e.g. 5001, 5002,etc.).

A second field MAX contains a count N of the maximum number of elements,e.g. the maximum number of agents which can log onto the system. Thenext field COUNT contains a signal which indicates the maximum number offree elements, e.g. the number of free agents. Immediately afterinitialization, the maximum number of elements equals the number of freeelements, shown as N.

The next field, HEAD, is an index pointer to the first record in thefree list 29 which is free. Immediately after initialization, it is torecord 1, as shown.

The last field, TAIL, is an index to the record of the youngestavailable element, shown as record N of the free list.

If a different scheme than oldest to youngest were used, HEAD wouldpoint to the record of the first element of the list, and TAIL to therecord of the last.

In use, the microprocessor 1 accesses the header. The pointer PTR pointsto free list 29 which contains the list of all idle agents. Theprocessor checks the header and then accesses the record of the element,e.g. agent, pointed to by the HEAD byte. In the case of FIG. 2, thepointer HEAD is to the first record in the free list 29.

The processor then routes the call to the agent designated by the numberstored in the record of the free list (e.g. agent 2), and changes thatrecord number to a special designator, such as -1, as shown in FIG. 3.The number stored in the HEAD byte is then changed to the numeral 2,designating record number 2, and the number stored in the COUNT byte isdecremented by 1.

FIG. 3 illustrates the state of the header 27 and free list 29 after thefirst three agents have been made busy and their records changed to -1.It may be seen that the number stored in the HEAD byte is 4, pointing tothe fourth record in the free list. The number stored in the COUNT byteis N-3, which indicates how many agents are left in the free list. Thefirst three records store the numeral -1, since the associated agentsare no longer free.

Thus when the processor wishes to connect the call to the longest idleagent, accessing the HEAD field in the header 27 points the processordirectly to record number 4 where the search begins for the longest idleagent in the requested hunt group. In case the COUNT has beendecremented to zero, the processor can route the incoming call to arecorded announcement. Each record needs to be read until the longestidle agent for the hunt group is found.

FIG. 4 illustrates the state of the header 27 and free list 29 after,for example agent or element designated by reference numeral 2 hascompleted its servicing of a call and is returned to the free list. Eachsuccessive digit number or element which becomes free is returned to therecord immediately following the record number of the youngest idleelement, which is designated by the content of the TAIL field in header27.

In FIG. 4, for example, the HEAD byte in header 27 points to record 4 inthe free list, which is the first agent in the free list, while the TAILbyte of header 27 indicates the last agent in the free list is agent 2.When scanning the free list, therefore, the oldest idle element would beindicated immediately as agent 4. Each field in the free list isaccessed sequentially, looping from the oldest to the newest record, theTAIL of the free list pointing to record number 2, which representsagent number 2. It may be seen in FIG. 4 that record N contains elementnumber 2, which had been placed in that record since agent 2 had beenreturned to the free list.

It may be seen that as there are only two elements in free list 29indicated as being busy, those designated in the first and third recordsas -1, the byte stored in the COUNT field of header 27 is N-2.

Items returned to the free list need not necessarily be placed as theyoungest record, but could be returned anywhere in the free list,depending on the application. Further, the processor could scan the freelist in any desired manner, not necessarily in a looping sequence fromthe oldest idle element to the youngest idle element, as describedabove.

In accordance with an embodiment of the present invention, the header 27in any such system is expanded as illustrated in FIG. 5 to include afield OWNRS which contains a pointer to an owner list 33. An entry inthis field is an indicator that the free list is resource ownershipmanaged.

The header also includes a field CNT, which contains a pointer to anowner count record 35 which contains fields containing a count of howmany owners there are of each of the resources, i.e. how many processeshave access to a particular resource during a particular time.

The owner list 33 and the owner count record 35 can be stored in a tableor tables in the same memory as free list 29.

The owner list and the owner count record are used to coordinate theallocation and release of resources to the proper owners.

Reference is now made to FIG. 6, which illustrates the owner list 33 andthe owner count record 35 in more detail. When ownership management isenabled, for example by reading the OWNRS field in header 27, a list ofowners for a given resource is stored in table 33. The list of owners intable 33 can be represented by a number of different data types, but canbe thought of logically as a two dimensional array as illustrated inFIGS. 5 and 6. In additional, a one dimensional array containing theowner count 35 is also used, to contain the number of owners for a givenresource instance.

The structure which stores resource owners has columns labeled num₋₋resources, wherein each column contains an identity of the owners(referred to herein simply as "owners" of a given resource instance. By"owners" is meant "the right to use"). The rows are labeled max₋₋ num₋₋owners, designating the quantities of resource owners that can be givenownership of a given resource.

In the example shown in FIG. 6, in the case of the resource instancecorresponding to the second column of the table, there are two entriescorresponding to its owners ownr7 and ownr4. The second element of theone dimensional array (the owner count 35) stores the number of ownersfor the resource instance corresponding to the second column of thetable, and in this case contains the number 2, corresponding to the twoentries for this resource. Similarly, the first entry of the onedimensional array stores the number 3, corresponding to the three ownersownrl, ownr6 and ownr3 of the resource corresponding to the first columnin the owner list array 33.

The purpose of ownership management is not solely to store owners, butalso to prevent certain potential owners from becoming owners of aresource. If we consider an example where the owners of resources areprocesses, a request by a process to obtain ownership of a resource maybe denied based on predetermined characteristics of the requester or ofthe current owners of a resource.

As functions of the free list management facility are called, the ownerlist and owner count of resources are updated to reflect the operationsperformed by these functions. It should be recognized that manydifferent types of owners can be allocated against resources, such asC++ or Smalltalk objects, processors, etc.

Five functions or routines can be used to implement a preferredembodiment of the present invention, as will be described below. 1. Afunction "initialize₋₋ free₋₋ list" should be called to initialize thefree list of available resources, and to set each resource's number ofowners to zero. Once initialized, the owner list 33 and the free list 35will be as shown in FIG. 5, wherein no owners are entered in the ownerlist, and the owner count for all resources is zero.

When this function is called, the selection criteria that must be metfor an owner to be successfully granted ownership of a resource shouldbe defined. These criteria can be defined in any number of ways, such asa function call, hard coded decision statements, etc. For example, anagent process can be hard coded logically so that it cannot own anotheragent resource, but a supervisor process can be hard coded logically sothat it is allowed to own any agent resource, or only certain agentresources.

This initialization function should be the first function of the freelist management facility called, since all other functions of thefacility should be able to assume that the structures have beeninitialized.

2. A function "get₋₋ resource" should be called to obtain a freeresource. When ownership management is enabled, this process is added tothe list of owners for the resource being allocated, if it meets theselection criteria defined when "initialize₋₋ free₋₋ list" was called.

3. A function "return₋₋ resource" should indicate that the owner nolonger requires a given resource, when called. The process which callsthis routine is removed from the resource's list of owners. If afterremoving the caller of this routine from the list of owners, the list isempty, the resource is returned to the free pool.

4. A function "add₋₋ ownership" should allow several owners, in thiscase processes, to share and use a common resource. One way by which aprocess can use an already allocated resource is through the use of thisfunction. By calling this function, a process is added to a resource'slist of owners if it meets the selection requirements defined when"initialize₋₋ free₋₋ list" was called.

5. A function "transfer₋₋ ownership", when called, should allow aprocess to pass ownership from one process to another. Thus when anowner has finished using a resource, instead of returning the resourceto the free pool, the owner can instead pass ownership on to anotherprocess. The process to receive ownership must meet the selectioncriteria that was defined when calling "initialize₋₋ free₋₋ list", orthe transfer should not be successful.

An example will be given below in which ownership management is made ofcall agents in an ACD system, where call agents are considered to beresources, and the owners of such resources are processes associatedwith call parties which talk with a call agent.

Before agents can be allocated and obtained, the free list managementfacility must be initialized for use. This is done by the main systemprocessor calling the function "initialize₋₋ free₋₋ list" with thefollowing parameters:

(a) The resource type of free list management facility to beinitialized. In this example, this would be agents.

(b) The number of agents in the system (N in this example).

(c) The selection criteria for ownership. In this example, the selectioncriteria can be encoded in a function called "can₋₋ become₋₋ owner₋₋of". An example in pseudo-code of the function is shown in FIG. 7.

(d) The maximum number of concurrent owners for a given resource type,e.g. 3.

The data structure resulting from calling the initialization routine isshown in FIG. 5.

When a customer calls an 800 or 888 number which is part of an ACDsystem that uses the present invention, the facility creates a processwhich is associated with the incoming call from the customer. Thisprocess will be referred to below as the customer process. This newlycreated process then tries to obtain an agent to service the customer'scall. To do this, the process calls the "get₋₋ resource" routine with,as a parameter, the resource type to be obtained, which is an agent inthis case.

Assuming that there are free agents, the customer process becomes anowner of an agent, is entered into the owner list 33 in the columnrelated to the agent, the owner count is incremented by one, and thecustomer's telephone line is connected to the telephone line of theagent by the telephone system, under control of the processor of thetelephone or ACD system.

FIG. 8 illustrates the state of the above-described data structures atthis stage. Agent No. 1 is updated in the free list 29 from agentavailability 2 (FIG. 5) to -1 (busy), as described in the aforenotedU.S. Pat. No. 5,515,428. The owner list 33 is updated to enter the owner(process) CUST in the column relating to the particular agent(resource), as may be seen by comparing FIG. 5 and 8). The owner countfor the particular agent is changed from 0 (FIG. 5) to 1 (FIG. 8).

Assume now that a supervisor is to be added to the conversation betweenthe customer and the agent. The supervisor must first add itself as anowner of the agent. To do this, the "add₋₋ ownership" routine is called,e.g. by the supervisor dialing a predetermined code which is detected bythe system processor, by closing a soft key switch on the telephone ofthe supervisor, etc. This results in the supervisor process SUP beingadded to the list of owners of the agent resource, as shown in FIG. 9,and the owner count for that resource being incremented from 1 to 2.

As noted earlier, the supervisor process cannot be added to the ownerlist unless it meets the selection requirement defined when"initialize₋₋ free₋₋ list" was called. When the supervisor requests thatit should join the conversation, as noted above, its associatedsupervisor process sends a message to the agent process and awaits anacknowledgment or rejection of the request. The agent process can readthe list of its owners from the owner's list to determine that therequest should be accepted. If the request is accepted, the agent,customer and supervisor processes perform a hand-off of their associatedcall to a conference process which manages them until any party leavesthe conference. At this point the conference process performs a hand-offof the parties back to the original processes for subsequent handling.

In the event that other parties are to join the conference, theconference process accepts or rejects the request by checking whetherthe other parties are listed as owners of the resource in the ownerlist.

In certain circumstances, a second agent may wish to consult a firstagent. In this case, the second agent will try to add itself (theidentity of its process) to the owner's list of the first agentresource, by the second agent's process calling the "add₋₋ ownership₋₋routine". The ownership may not be granted, if the function shown inFIG. 7 returns FALSE. In this manner, the second agent process is barredfrom obtaining ownership of the first agent resource, and the lines ofthe two agents will not be connected by the system.

In the termination of the conference call between the customer, theagent and the supervisor, e.g. when the customer hangs up, the customerprocess calls the "return₋₋ resource" routine to indicate that thecustomer process no longer requires the use of the agent resource. The"return₋₋ resource" routine modifies the owner list entry for the agentto remove the CUST process owner, leaving the SUP process owner listedin the agent resource column, as shown in FIG. 10. The owner count forthe agent resource is decremented by one from 2 to 1. Since an owner ofthe resource still exists (SUP), the availability of the agent in thefree list remains -1, indicating that the agent is not available to takeadditional calls, and the agent is not returned to the free pool.

The conversation at this point is between the agent and the supervisor,since the customer has hung up.

When the supervisor hangs up, the supervisor's process calls the"return₋₋ resource" routine for the agent. The process SUP is removedfrom the agent resource record, resulting in the owner list as shown inFIG. 11. Since the supervisor's process was the only remaining owner,the owner count for the resource is decremented to 0, and the free listfor the resource is changed from -1 to 0, indicating that the resourceis free.

It will be recognized that the identity of the owner can be differentthan that described; for example the process identifier can be any datathat will indicate a particular owner can own or operate the resource.The acceptance criteria used, when adding a new owner to the resource,can be changed at any time, including during the processing of a call.

While the example given above was specific to the processing of an ACDfeature of a telephone switching system, the invention can be used forother purposes, such as to manage all subscriber calls in a PABX system.When a subscriber call is delivered to any destination, the destinationcan become owned by the subscriber process and a busy process. Allsubsequent calls to the destination would use the multiple ownerresource management system described above to request ownership of thedestination (i.e. accepted into the call in progress, or rejected fromjoining the call in progress), and to release the destination (drop fromthe call). When all owners of the destination have released ownershipthe destination becomes idle (free) and available for any new call.

A person understanding this invention may now conceive of alternativestructures and embodiments or variations of the above. All those whichfall within the scope of the claims appended hereto are considered to bepart of the present invention.

We claim:
 1. A method of management of multiple resources in a multipleprocess system having resources adapted to be owned by at least oneprocess, said method comprising:(a) providing a free list of allresources, (b) providing an owner list of resources indicating whichprocesses are permitted ownership of each resource, (c) storing in saidowner list the identity of a process owning a resource which saidprocess has a right to own, (d) allowing only a process listed with aresource in said owner list to own the resource, and (e) marking aresource in the free list as busy when said resource is owned by aprocess stored with it in the owner list, and marking the resource inthe free list as available when the resource in the free list is notowned by a process stored with it in said owner list.
 2. A method asdefined in claim 1, including (f) barring access to a resource to otherprocesses when a process is listed as owning said resource and saidresource is busy.
 3. A method as defined in claim 1 in which the systemis a PABX, resources are lines and trunks, and processes are incomingand outgoing call PABX control routines.
 4. A method as defined in claim1 including adding a further process to said owners list of a busyresource and allowing said further process to share ownership of saidbusy resource.
 5. A method as defined in claim 4 including allowing saidfurther process to share ownership of a busy resource if said furtherprocess has shared ownership access permission.
 6. A method as definedin claim 4 in which the system is an automatic call distribution (ACD)facility, resources are call agents, and processes are incoming call(customer) processes, supervisor processes and free agent processes.